Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[nerdctl build] Set default output type=image #3604

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

TinaMor
Copy link
Contributor

@TinaMor TinaMor commented Oct 28, 2024

PR Description

Linked Issue: containerd/nerdctl#3629

This PR resolves #3629 for nerdctl build command when passed with:

  1. --progress auto, --progress tty, or --progress flag is not specified (which then defaults to --progress auto)
  2. --output flag is not specified

Example:

nerdctl build -t <TAG> --file .\Dockerfile .

Background

The issue occurs because the build progress output and the tarball are both sent to stdout on WIndows.

Solution

output = "type=docker"

When a user does not specify the --output flag, we default it to use type=image instead of type=docker because the image is actually uploaded to containerd image store. According to buildctl documentation, type=image is the native type for containerd.

Additional tasks

  • Only use the default image name when user has not specified one

Not included in this PR

  1. When default type=oci
    output = "type=oci"
  2. type=docker
    Currenly fails with archive/tar: invalid tar header moby/buildkit/issues/5528

References

  1. buildctl output: containerd image store

@TinaMor TinaMor force-pushed the tinamor/fix-build-with-tty branch 4 times, most recently from 2d18366 to 01db27a Compare October 29, 2024 14:23
@TinaMor TinaMor changed the title Separate TTY and tar output in nerdctl build with tty Fix Windows tar parsing error by separating tty and tar outputs in buildctl Oct 29, 2024
@TinaMor TinaMor changed the title Fix Windows tar parsing error by separating tty and tar outputs in buildctl [Windows] Fix nerdctl build tar parsing error Oct 29, 2024
@TBBle
Copy link
Contributor

TBBle commented Nov 1, 2024

I need to work through this later, but I'm unclear how the current code works on non-Windows. How do those platforms distinguish a tar file from log output on stdout?

They shouldn't be passing through a termInal on the way, the terminal is where nerdctl's stdio is connected, so I don't understand what's different on Windows.

@apostasie
Copy link
Contributor

apostasie commented Nov 1, 2024

Hey @TBBle
I’ll have a look later today.
Curious too.

@AkihiroSuda AkihiroSuda added the area/ci e.g., CI failure label Nov 1, 2024
@TinaMor
Copy link
Contributor Author

TinaMor commented Nov 5, 2024

@TBBle, @apostasie

Still investigating the issue. This is a temp fix and the PR is WIP (may and may not be the final solution).
Currrently trying to understand the following:

  1. What is the performance impact of this fix if using a larger image eg mcr.microsoft.com/windows/servercore:ltsc2022 vs mcr.microsoft.com/windows/nanoserver:ltsc2022
  2. Is it the Windows terminal?
  3. Why are the build output and tarball all going to the same location on Windows alone?
  4. How does it work for progress=plain?

@apostasie
Copy link
Contributor

Deeply confused about this.

Why are the build output and tarball all going to the same location on Windows alone?

This does not make any sense.
I am squinting at nerdctl source and cannot figure it out.

Now suspecting buildctl might be the problem.

@apostasie
Copy link
Contributor

buildctl "output" goes to stderr.

Is it the case on windows?

foo="$(buildctl --addr=unix:///run/user/501/buildkit/buildkitd.sock build --progress=auto --frontend=dockerfile.v0 --local=context=/tmp/ --output=type=docker --local=dockerfile=/tmp --opt=filename=Dockerfile)"

or

buildctl --addr=unix:///run/user/501/buildkit/buildkitd.sock build --progress=auto --frontend=dockerfile.v0 --local=context=/tmp/ --output=type=docker --local=dockerfile=/tmp --opt=filename=Dockerfile >/dev/null

@TinaMor TinaMor force-pushed the tinamor/fix-build-with-tty branch from 01db27a to 1e7bbf4 Compare November 6, 2024 15:24
@TinaMor TinaMor changed the title [Windows] Fix nerdctl build tar parsing error [nerdctl build] Set default output type=image Nov 6, 2024
@TinaMor TinaMor force-pushed the tinamor/fix-build-with-tty branch from 1e7bbf4 to 80dc420 Compare November 13, 2024 13:54
output = "type=docker"
// https://github.com/moby/buildkit?tab=readme-ov-file#output
// type=image is the native type for containerd
output = "type=image"
Copy link
Contributor Author

@TinaMor TinaMor Nov 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Default to type=image instead of type=docker. See #3604 (comment)

cc @profnandaa

if err != nil {
if r.N == 0 {
// Avoid confusing "unrecognized image format"
return errors.New("no image was built")
return fmt.Errorf("no image was built: %w", err)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make the error more descriptive by adding the actual error

pkg/cmd/builder/build.go Outdated Show resolved Hide resolved
@TinaMor TinaMor closed this Nov 13, 2024
@TinaMor TinaMor reopened this Nov 13, 2024
@TinaMor TinaMor force-pushed the tinamor/fix-build-with-tty branch from 9581c2c to 14392ff Compare November 13, 2024 16:03
    - Use default image name only when user has not specified one

Signed-off-by: Christine Murimi <mor.devx@outlook.com>
@TinaMor TinaMor force-pushed the tinamor/fix-build-with-tty branch from 14392ff to f4728b4 Compare November 13, 2024 16:16
@TBBle
Copy link
Contributor

TBBle commented Nov 14, 2024

When a user does not specify the --output flag, we default it to use type=image instead of type=docker because the image is actually uploaded to containerd image store. According to buildctl documentation, type=image is the native type for containerd.

Does this introduce a requirement that buildkit is configured to use the containerd worker? Or is that already a requirement for using nerdctl build for other reasons?

@@ -89,17 +89,17 @@ CMD ["echo", "nerdctl-build-test-string"]`, testutil.CommonImage)
Expected: test.Expects(0, nil, test.Equals("nerdctl-build-test-string\n")),
},
{
Description: "Successfully build with output docker, name cannot be used",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@apostasie I've removed this test for now. I may be missing something. What is this testing?

@TinaMor
Copy link
Contributor Author

TinaMor commented Nov 19, 2024

Does this introduce a requirement that buildkit is configured to use the containerd worker? Or is that already a requirement for using nerdctl build for other reasons?

@TBBle In Windows, containerd-worker is the default. There is ongoing work to support oci-worker on Windows. On Linux environments, [oci-worker is the default].(https://github.com/moby/buildkit/blob/5cd5a63de5d37512c24f20085607509b749df762/README.md#linux-setup)

Additionally, with the shift from docker to containerd, we then should switch to using type=image instead of type=docker as the default, for both Windows and Linux.

References:

  1. What is the difference between oci workers and containerd workers?
  2. Docker vs. Containerd: Understanding the Shift in Kubernetes

@AkihiroSuda @jsturtevant What do you think?

@AkihiroSuda
Copy link
Member

The OCI worker still has to be supported

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ci e.g., CI failure
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error: no image was built
4 participants